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(54) Copyrighted data processing method and apparatus 

(57) A distributed data storage unit(1 1 ) stores music 
data including one or more contents(42) and billing 
information(43). A purchase process unit(13) obtains a 
process right to the music data through communica- 
tions. A data conversion unit(14) separates the billing 
information (43) from the music data that can be proc- 
essed with the obtained process right, and converts the 
resultant data into an internal format. The converted 
music data is stored in an internal data storage unit(15). 
At the same time, the data conversion unit(14) extracts 
decryption keys from the billing information(43), and 
records the extracted decryption keys in a copyright 
management table(16). A control unit(17) carries out 
uniform copyright management using the copyright 
management table(16), and instructs a playback 
unit(18) or a check-ouVcheck-in unit(19) to process the 
converted music data. 
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Description 

BACKGROUND OF THE INVENTION 

Held of the invention 5 

[0001] The present invention is related to a method 
and apparatus for processing copyrighted data, and 
more specifically, to a method and apparatus for 
processing copyrighted data distributed through a net- w 
work. 

Description of the Background Art 

[0002] In recent years, various pieces of information is 
have become widely available, and a large number of 
digital productions have been distributed with multime- 
dia contents including images and sounds. Such digital 
productions are provided for users through recording 
media such as CD-ROMs or communication means 20 
such as the Internet. Especially, downloading digital 
productions to personal computers through a communi- 
cation network is a convenient distribution method, and 
therefore this method is expected to wildly spread. Dig- 
ital productions are easy to copy without deteriorating in 25 
characteristic. For this reason, copyright protection for 
digital productions is highly required. 
[0003] For protecting copyright for digital produc- 
tions, the following conventional arts have been known. 
A first conventional art is a content control method used 30 
in a music distribution system, which has been pub- 
lished In "Internet-based music distribution requires 
immediate improvements in copyright protection tech- 
nologies", Nikkei Electronics, Issue, no. 738, March, 8, 
1999, PR 87-111. In the content control method, a file 35 
containing encrypted music data (hereinafter referred to 
as file A) and a file containing control information, a 
decryption key for decrypting the file A, and others 
(hereinafter referred to as file B) are distributed through 
a communication network. To play back the music data 40 
contained in the file A, it is determined, with reference to 
the control Information contained In the file B ( whether 
or not the file A is allowed to be played back or copied. 
[0004] FIG. 46 is a block diagram showing the 
structure of a data processing apparatus using the first 45 
conventional art. The data processing apparatus shown 
in FIG. 46 is connected to a communication network 
(not shown) when in use. A distributed data storage unit 
101 stores the file A distributed through a communica- 
tion network such as the Internet and CATV (Cable TV), so 
A copyright management table 1 02 stores the file B dis- 
tributed through the communication network corre- 
sponding to the file A. A purchase process unit 103 
communicates with a billing server (not shown) to pur- 
chase a process right required for playback and other ss 
processes, and records the purchased process right In 
the copyright management table 102. When an instruc- 
tion is inputted by using an input unit 104, a control unit 



105 determines, with reference to the process right 
recorded in the copyright management table 102, 
whether the instruction is to be executed or not A play- 
back unit 1 06 receives a decryption key contained in the 
file B from the control unit 1 05, and plays back the music 
data contained in the file A. 

[0005] As a second conventional art, a method of 
preventing unauthorized copy by encrypting digital data 
has been known, which is disclosed in Japanese Patent 
Lald-Open Publication No. 9-320192 (1997-320192). 
FIG. 47 is a diagram showing the structure of a copy- 
right protection apparatus according to the second con- 
ventional art. The copyright protection apparatus shown 
in FIG. 47 is characterized in that digital data read from 
a disk 1 11 is encrypted before being placed on a bus 
1 14. In other words, a data format unit 112 provides the 
data read from the disk 1 1 1 with encryption start Infor- 
mation, an encryption key, Information about a unit of 
encryption, copy management information indicating 
whether data copy is allowed or not, and identification 
information of an encryption algorithm to be used. An 
encryption unit 113 encrypts the data using the encryp- 
tion key provided by a key delivery unit 110. The 
encrypted data flows on the bus 1 14. A decryption unit 
115 decrypts the data using a decryption key provided 
by the key delivery unit 110. The decrypted data is 
restored by a data format unit 1 1 6 to the state as it was 
read from the disk 111, and then played back by a play- 
back unit 11 7. 

[0006] As such, according to the first conventional 
art, received copyrighted data can be processed within 
a purchased process right, while, according to the sec- 
ond one, copyrighted data can be protected from unau- 
thorized copy. 

[0007] In these conventional arts, however, details 
on how to handle received copyrighted data are not dis- 
closed. Especially, a format in which data processing 
apparatus handles copyrighted data is not disclosed. 
[0008] In a music distribution system, for example, 
a data processing apparatus for processing music data 
receives music data through a communication network, 
and copies the received music data to an external stor- 
age medium. The data processing apparatus is pro- 
vided with music data from many providers. Since the 
copyright of the music data belongs to each providers, 
the music data is distributed with a format unique to 
each provider. Also, the music data can be copied to 
various types of external storage media such as DVD- 
RAMs and memory cards. Therefore, when being cop- 
ied to the external storage medium, the distributed 
music data has to be converted into a format specified 
for each type of external storage medium. 
[0009] Under circumstances where many providers 
and many types of external storage media are present 
as described above, distributed copyrighted data cannot 
be efficiently processed with the above background arts 
because these arts do not disclose the format in which 
copyrighted data is handled. 
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SUMMARY OF THE INVENTION 

[001 0] Therefore, an object of the present Invention 
is to provide a copyrighted data processing apparatus 
for efficiently processing copyrighted data by converting 
the copyrighted data distributed through a communica- 
tion network into an internal format suitable for the fol- 
lowing process. 

[0011] The present invention has the following fea- 
tures to achieve the object above. 
[0012] A first aspect of the present invention is 
directed to a data processing apparatus executing a 
process on copyrighted data within a right obtained, 
comprising: a data receiving unit operable to receive 
distribution-format data including at least content data 
for protection and billing information defining a billing 
condition on the content data; a right purchasing unit 
operable to carry out payment based on the billing infor- 
mation and obtain a process right required for the proc- 
ess on the content data; a right information storage unit 
operable to store the process right obtained by the right 
purchasing unit; a data conversion unit operable to con- 
vert the distribution-format data including the content 
data into internal-format data without the billing informa- 
tion when the process right Is obtained for the content 
data; a data storage unit operable to store the internal- 
format data obtained by the data conversion unit; and a 
process execution unit operable to execute the process 
on the internal-format data stored in the data storage 
unit within the process right stored in the right informa- 
tion storage unit. 

[0013] With such data processing apparatus, the 
copyrighted data is converted into internal-format data 
without the billing information, and then stored. There- 
fore, the data can be processed variously under copy- 
right management through a uniform procedure, 
irrespective of the billing method. 
[0014] Further, when the content data may be 
encrypted, and the billing information includes a decryp- 
tion key for decrypting encryption of the content data, 
the decryption key may be extracted from the billing 
information by the data conversion unit, and stored in a 
right information storage unit A process execution unit 
may decrypt the encryption of the content data using 
the decryption key. In this way, the decryption key is 
managed with the right information storage unit, thereby 
enabling data decryption through a uniform procedure, 
irrespective of the method of distributing the decryption 
key. 

[0015] Still further, the distribution-format data may 
include the content data, the billing information, a 
header, and process execution control information to 
control process execution for the content data. The data 
processing apparatus for processing such data can 
control execution of the data process as intended by the 
content data creator with the use of the process execu- 
tion control information. 

[0016] Still further, the internal-format data may be 



equal to data obtained by separating only the billing 
information from the distribution-format data. With this, 
the process in the data conversion unit becomes easy, 
and the processing speed of the data processing appa- 

5 ratus can be improved. 

[001 7] According to a second aspect of the present 
invention in regard to the first aspect, the process exe- 
cution unit comprises a data copy unit operable to copy 
the internal-format data stored in the data storage unit 

w to a removable storage medium, and the data conver- 
sion unit converts the distribution-format data into the 
internal-format data based on a type of the storage 
medium. More preferably, the data processing appara- 
tus may further comprise a storage medium detection 

15 unit operable to detect the type of the storage medium 
or a storage medium specifying unit operable to specify 
the type of the storage medium, and the data conver- 
sion unit may convert the distribution-format data Into 
the internal-format data based on the type of the stor- 

20 age medium detected or specified by these units. 

[0018] In such data processing apparatus, the cop- 
yrighted data is converted into the internal-format data 
suitable for the type of the storage medium, and then 
stored. Therefore, an amount of data In the data 

25 processing apparatus can be reduced. 

[0019] Still further, if the distribution-format data 
includes one or more pieces of the content data, the 
internal-format data may include only content data to be 
copied to the storage medium among the one or more 

30 pieces of the content data. By selecting and storing only 
required content data, the amount of data can be greatly 
reduced. 

[0020] A third aspect of the present invention is 
directed to a data processing method for executing a 

35 process on copyrighted data within a right obtained, 
comprising: a data receiving step of receiving distribu- 
tion-format data including at least content data for pro- 
tection and billing information defining a billing condition 
on the content data; a right purchasing step of process- 

40 ing purchasing based on the billing information and 
obtaining a process right required for the process on the 
content data; a right information storing step of storing 
the process right obtained in the right purchasing step; 
a data converting step of converting the distribution-for- 

45 mat data including the content data into internal-format 
data without the billing information when the process 
right is obtained for the content data; a data storing step 
of storing the internal-format data obtained in the data 
converting step; and a process executing step of exe- 

so cuting the process on the internal-format data stored in 
the data storing step within the process right stored in 
the right information storing step. 
[0021] A fourth aspect of the present invention is 
directed to a recording medium recording a program for 

55 executing, on a computer, the data processing method 
of the third aspect of the present invention. 
[0022] According to the third or fourth aspect of the 
invention, the copyrighted data is converted into the 
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Internal-format data without the billing information, and 
then stored. Therefore, the data can be processed vari- 
ously under copyright management through a uniform 
procedure, irrespective of the billing method. 
[0023] As stated above, the copyrighted data 
processing method and apparatus according to the 
present invention provide the user with excellent usabil- 
ity, which is quite effective In practical use. 
[0024] These and other objects, features, aspects, 
and advantages of the present invention will become 
more apparent from the following detailed description of 
the present invention when taken in conjunction with the 
accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0025] 

FIG. 1 is a block diagram showing the structure of a 
data processing apparatus according to a first 
embodiment of the present invention; 
FIG. 2 is a diagram showing the structure of a 
music distribution system using the data processing 
apparatus according to the first embodiment; 
FIGS. 3a to 3c are diagrams showing formats of 
music data to be handled by the data processing 
apparatus according to the first embodiment; 
FIG. 4 shows an example of a purchase manage- 
ment table in the data processing apparatus 
according to the first embodiment; 
FIG. 5 shows an example of a copyright manage- 
ment table in the data processing apparatus 
according to the first embodiment; 
FIG. 6 is a flowchart showing the operation of a 
control unit in the data processing apparatus 
according to the first embodiment; 
FIG. 7 is a flowchart showing the operation of a pur- 
chase process unit in the data processing appara- 
tus according to the first embodiment; 
FIG. 8 is another diagram showing the music distri- 
bution system using the data processing apparatus 
according to the first embodiment; 
FIG. 9 is a block diagram showing the structure of a 
data processing apparatus according to a second 
embodiment of the present invention; 
FIG. 10 is a flowchart showing the operation of a 
data conversion unit in the data processing appara- 
tus according to the second embodiment; 
FIG. 11 is a flowchart showing the detailed opera- 
tion of the data conversion unit In the data process- 
ing apparatus according to the second 
embodiment; 

FIG. 12 is an example of a package management 
table in the data processing apparatus according to 
the second embodiment; 

FIGS. 13a to 13c are diagrams showing the effect 
of data conversion process in the data processing 
apparatus according to the second embodiment; 



FIG. 14 is a diagram showing another format of 
music data handled by the data processing appara- 
tus according to the second embodiment; 
FIG. 15 is a block diagram showing the structure of 

5 a data processing apparatus according to a third 

embodiment of the present invention; 
FIG. 16 is a diagram showing a screen for specify- 
ing an external storage medium by the data 
processing apparatus according to the third embod- 

70 Iment; 

FIG. 17 is a flowchart showing the operation of a 
data conversion unit in the data processing appara- 
tus according to the third embodiment; 
FIG. 18 is a diagram showing the structure of an 

is SDAF package according to a fourth embodiment 
of the present invention; 

FIGS. 19a to 19c are diagrams showing other struc- 
tures of the SDAF packages; 
FIG. 20 is a diagram showing how to split an SDAF 
20 title into SDAF packages; 

FIG. 21 is a diagram showing an example of the 
SDAF package; 

FIG. 22 is a diagram showing a header structure; 

FIGS. 23 and 24 show source codes describing the 
25 header structure using the C++ language; 

FIGS. 25a to 25c are diagrams showing how to 

define a CEL attribute table using a tag structure; 

FIG. 26 is a diagram showing a correspondence 

between key pairs and CELs; 
30 FIG. 27 shows source codes describing the key pair 

structure using the C++ language; 

FIG. 28 is a diagram showing how to refer to the 

CEL from navigation data; 

FIGS. 29 and 30 are diagrams showing the struc- 
35 ture of the navigation data; 

FIG. 31 is a table showing specifications of 

MPEG2-AAC applied to audio CEL; 

FIG. 32 is a table showing specifications of JPEG 

applied to an image CEL; 
40 FIG. 33 is a table showing specifications of MPEG- 

I frame applied to the image CEL; 

FIG. 34 is a table showing specifications of PNG 

applied to the image CEL; 

FIG. 35 is a table showing specifications of MPEG2 
45 applied to a video CEL; 

FIG. 36 is a diagram showing the structure of a time 
search map; 

FIGS. 37, 38a, and 38b are a table and diagrams 
showing a header included in the time search map 
so in detail; 

FIG. 39 is a table showing each entry included in 

the time search map in detail; 

FIG. 40 is a table showing an example of CEL redi- 

rectors; 

55 FIGS. 41a to 41c are diagrams showing examples 
of how to distribute the SDAF package; 
FIGS. 42a to 42c are diagrams showing examples 
of how to create the SDAF package; 
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FIG. 43 Is an external view of a portable music 
player; 

FIGS. 44 and 45 are block diagrams showing the 
structure of the data conversion unit; 
FIG. 46 is a block diagram showing the structure of 
a conventional data processing apparatus; and 
FIG. 47 is a block diagram showing the structure of 
a conventional copyright protection apparatus. 

DESCRIPTION OF THE PREFERRED EMBODI- 
MENTS 

[0026] With reference to the drawings, embodi- 
ments of the present Invention are described below. 
First, as first to third embodiments, data conversion 
apparatuses for converting distributed copyrighted data 
into a predetermined internal format are described. 
Thereafter, as a fourth embodiment, a specific example 
of the copyrighted data according to the first to third 
embodiments are described in detail. 
[0027] Note that the copyrighted data according to 
the fourth embodiment is merely an example of that 
according to the first to third embodiments, and it goes 
without saying that the data processing apparatuses 
according to the first to third embodiments may handle 
other copyrighted data. Moreover, although description 
will be made herein assuming that copyrighted data is 
music data, the copyrighted data in the present inven- 
tion is not restricted to the music data, but may also be 
image data, text data, or combination of both and music 
data . 

(First Embodiment) 



[0028] FIG. 1 is a block diagram showing the struc- 
ture of the data processing apparatus according to the 
first embodiment of the present invention. The data 
processing apparatus 1 shown in FIG. 1 includes an 
input unit 10, a distributed data storage unit 11, a pur- 
chase management table 12, a purchase process unit 
13, a data conversion unit 14, an internal data storage 
unit 15, a copyright management table 16, a control unit 
1 7, a playback unit 1 8, a check-out/check-in unit 1 9, and 
a display unit 21. The. data processing apparatus 1 car- 
ries out playback, copy, and other processes on distrib- 
uted copyrighted music data, and is characterized in 
that the distributed music data is converted into an inter- 
nal format for storage. 

[00291 Prior to detailed description of the data 
processing apparatus 1, music distribution system 
using the data processing apparatus 1 and formats of 
music data handled in the data processing apparatus 1 
are now described with reference to FIGS. 2 and 3. 
[0030] As shown in FIG. 2, the data processing 
apparatus 1 is connected through a communication net- 
work 4 to a distribution server 5 and a billing server 6. 
The communication network 4 is a network such as the 
Internet, or a network for CATV, satellite communica- 



tions, or cellular phones. The distribution server 5 stores 
a large amount of copyrighted music data. In response 
to a request from the data processing apparatus 1 , the 
distribution server 5 distributes the music data. The bill- 

5 ing server 6 carries out a billing process for the distrib- 
uted music data External storage media 7 are 
structured removable from both the data processing 
apparatus 1 and a portable music player 8. The data 
processing apparatus 1 identifies each external storage 

10 medium 7 by using a storage medium identifier unique 
to each medium 7 or a label name specified by the user 
for each medium 7. 

[0031] Copyright management for music data is 
now briefly described below. The distribution server 5 

is distributes encrypted music data and decryption keys 
for decryption to the data processing apparatus 1. The 
data processing apparatus 1 transmits information that 
the user agrees to pay for the music data to the billing 
server 6 before or after distribution in order to purchase 

20 a process right to the distributed music data. For exam- 
ple, the data processing apparatus 1 plays back the 
music data using the decryption keys as many times as 
the number of playbacks specified by the purchased 

right 4 . 

25 [0032] Moreover, the data processing apparatus 1 
can copy the music data and decryption keys to the 
external recording medium 7 (such processing hereinaf- 
ter referred to as check-out) and delete the copied 
music data from the external recording medium 7 (such 
so processing hereinafter referred to as check-in). The 
data processing apparatus 1 can check out the music 
data as many times as the number of check-outs speci- 
fied by the purchased right. A check-out right that allows 
check-out once is recovered when the checked-out data 
35 Is checked in. However, the music data can be checked 
In only by the data apparatus that has checked out the 
music data. Moreover, if the external storage medium to 
which edit-protected music data is checked out is writ- 
ten upon, the data processing apparatus 1 does not 
40 check in the music data 

[0033] The music data handled by the data 
processing apparatus 1 includes, In addition to audio 
contents, contents such as video, images, text, and pro- 
grams. FIGS. 3a to 3c are diagrams showing three 
45 music data formats handled by the data processing 
apparatus 1. A distribution format shown in FIG. 3a is 
used for distributing the music data. An internal format 
shown in FIG. 3b is used for storing the music data in 
the data processing apparatus 1 . A copy format shown 
so in FIG. 3c is used for checking out the music data to the 
external storage medium 7. 

[0034] The music data is distributed to the data 
processing apparatus 1 by a unit called package. In the 
distribution format shown in FIG. 3a, the package is 
55 composed of four data items: a header 40, navigation 
Information 41, one or more contents 42, and billing 
information 43. The header 40 includes information 
such as a package identifier for identifying the package 



5 



9 



EP 1 081 574 A1 



10 



and Information about the position and size of other 
data. The content 42 is content data such as audio, 
video, images, text, or programs. Each content has its 
own content identifier that is unique within the package, 
and is encrypted as required. 

[0035] The navigation information 41 is used as 
playback control information used for controlling music 
data playback. For referring to each content 42 from the 
navigation information 41 , the content identifier is used. 
A content included in the package to which the naviga- 
tion information belong is referred to only with its con- 
tent identifier, while a content in another package is 
referred to with its package identifier and content identi- 
fier. The billing information 43 includes a use condition, 
price, and decryption key for each content 42. 
[0036] In the data processing apparatus 1, the 
music data is handled with the billing Information 43 
separated therefrom. In the internal format shown in 
FIG. 3b, the music data is composed of the header 40, 
the navigation information 41 , and the contents 42. 
[0037] The music data is converted into a format 
appropriate to the type of the external recording 
medium 7 before being checked out thereto. For exam- 
ple, if the external storage medium 7 is an SD (Secure 
Digital) memory card, the music data is converted into a 
format so that audio contents for the SD memory card 
are included and video contents are not included 
therein. In the copy format shown in FIG. 3c, the music 
data is composed of a header 44, the content 42, and 
the decryption key 45. The header 44 conforms to the 
type of the external storage medium 7. The decryption 
key 45 is extracted from the billing information 43 in the 
distribution format The content 42 is content data 
selected based on the type of the external storage 
medium 7 from the music data in the internal format 
The music data shown in FIG. 3c includes only a single 
content 42, but may include one or more contents. 
When the music data is checked out, the music data in 
the copy format may be split into a plurality of files for 
copy. 

[0038] Referring back to FIG. 1 , the structure of the 
data processing apparatus 1 is described below. The 
operation of the data processing apparatus 1 is now 
briefly described. The distributed music data is con- 
verted into an internal format by the data conversion 
unit 14, and then stored in the internal data storage unit 
15. Information about the right to process each content 
included in the music data is recorded in the copyright 
management table 16. The control unit 17 refers to the 
copyright management table 16 to determine whether 
an inputted instruction 30 is to be executed or not. If 
determining that the instruction Is to be executed, the 
control unit 17 makes an instruction for starting play- 
back, check-out, and other process. 
[0039] The user inputs the instruction 30 for the 
content with the input unit 10. The instructions 
described in the present embodiment are those for dis- 
tribution, purchasing, playback, check-out, and check- 



in. In addition, other examples include, move, mode set- 
ting, instructions for data classification, data editing, 
data search, import, export, adding user data, taking in 
ripped contents, and authorization check. 

5 [0040] The distributed data storage unit 11 stores 
music data in a distribution format distributed by the dis- 
tribution server 5. The purchase management table 12 
stores, as shown in FIG. 4, a package identifier 50, a 
content identifier 51 , and a purchase condition 52 as a 

io set for each content included in the music data stored in 
the distributed data storage unit 1 1 . The purchase con- 
dition is specified at the purchase of the content. For 
example, such condition includes playback only, full pur- 
chase, and test-listening. If the purchase condition is 

15 playback only, the content can be played back only a 
specified number of times or only in a specified period. 
If the purchase condition Is full purchase, the content 
can be freely played back and checked out only a spec- 
ified number of times, if the purchase condition is test- 

20 listening, the content can be played back an unlimited 
number of times within a specified time period. 
[0041] When receiving from the input unit 10 the 
instruction 30 for purchasing, the purchase process unit 
13 sends information that the user agrees to pay the 

25 music data to the billing server 6 to purchase a right to 
the distributed music data. Thereafter, the purchase 
processing unit 13 records the purchased process right 
in the purchase management table 12. If the specified 
content is not stored in the distributed data storage unit 

30 11, the purchase process unit 13 requests the distribu- 
tion server 5 to distribute the music data containing the 
content. After receiving the music data, the purchase 
processing unit 13 provides the data conversion unit 14 
with a control signal 31 for instructing data conversion. 

35 [0042] Receiving the control signal 31, the data 
conversion unit 14 converts the specified music data 
into the internal format In other words, the data conver- 
sion unit 14 separates the billing information 43 from the 
distributed package to obtain the music data in the lnter- 

40 nal format. The data conversion unit 1 4 also extracts the 
decryption key 54 for each content from the billing infor- 
mation 43, and records the decryption key in the copy- 
right management table 1 6. 

[0043] The internal data storage unit 15 stores the 
45 music data in the internal format outputted from the data 
conversion unit 14. The stored music data is to be 
played back, checked out, etc. 

[0044] The copyright management table 16 stores, 
as shown in FIG. 5, copyright management information 

so for each content stored in the internal data storage unit 
15. The copyright management table 16 includes the 
package identifier 50, the content Identifier 51, the pur- 
chase condition 52, date of right purchasing 53, a 
decryption key 54, the number of playbacks 55, the 

55 number of check-outs 56, and check-out destination 
information 57. Note that FIG. 5 shows a single table 
divided into two parts indicated by (a) and (b), and in the 
table before being divided, the number of playbacks 55 
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follows the decryption key 54. 

[0045] The package identifier 50, the content identi- 
fier 51, and the purchase condition 52 are the same 
data as that stored in the purchase management table 
1 2 The date of right purchasing 53 indicates the date of 
purchasing the content. The decryption key 54 is used 
to decrypt encryption of the content. The number of 
playbacks 55 indicates the number of times the content 
has been played back. The number of check-outs 56 
indicates the number of times the content has been 
checked out. The check-out destination information 57 
includes a storage medium identifier and a label name 
for the external storage medium to which the content 
has been checked out The label name is assigned to 
the external storage medium when the music data is 
first checked out thereto. 

[0046] The package identifier 50, the content identi- 
fier 51 , the purchase condition 52, the date of right pur- 
chasing 53, and the decryption key 54 are set to 
predetermined values when new music data is stored in 
the internal data storage unit 15. The package Identifier 
50, the content identifier 51 , and the purchase condition 
52 are set to values provided by the purchase process 
unit 1 3, while the decryption key 54 is set to a value pro- 
vided by the data conversion unit 14. The number of 
playbacks 55 and the number of check-outs 56 are ini- 
tialized to 0, while the check-out destination information 
57 is cleared. The copyright management table 16 is 
encrypted with an encryption method unique to the data 
processing apparatus 1 for protection against data tam- 
pering. . 
[0047] The control unit 17 refers to the copyright 
management table 16 to determine whether the instruc- 
tion 30 is to be executed or not. When determining that 
the instruction 30 is to be executed, the control unit 17 
makes an instruction for starting playback or check-out. 
With reference to a flowchart shown in FIG. 6, the oper- 
ation of the control unit 17 is now described. When 
receiving the instruction 30 for the content (step S1 01 ), 
the control unit 17 reads the copyright management 
information of that content from the copyright manage- 
ment table (step S102). The control unit 17 then uses 
the read copyright management information to deter- 
mine whether the instruction 30 is to be executed or not 
(step S103). For example, when receiving a playback 
instruction, the control unit 17 refers to the number of 
allowable playback or the allowable playback period 
included in the purchase condition 52. If the number of 
playbacks is not more than the number of allowable 
playbacks or if today is within the allowable playback 
period after the date of right purchasing 53, the control 
unit 1 7 determines that the playback instruction is to be 
executed. 

[0048] When determining that the instruction is to 
be executed, the control unit 17 updates the number of 
playbacks 55, the number of check-outs 56, or other rel- 
evant items included in the copyright management table 
16 (step S104). The control unit 17 then outputs a con- 



trol signal 32 for starting the process to a relevant proc- 
ess execution unit (step S105). At this time, the control 
unit 1 7 also outputs the decryption key 54 read from the 
copyright management table 1 6 as being included in the 
5 control signal 32. On the other hand, when determining 
that the instruction is not to be executed, the control unit 
17 outputs the control signal 32 for warning display to 
the display unit 21 (step S106). 
[0049] When receiving the control signal 32 for 
io starting playback, the playback unit 1 8 reads the speci- 
fied content from the music data stored in the internal 
data storage unit 15, and plays back the content using 
the received decryption key 54. 
[0050] When receiving the control signal 32 for 
is starting check-out, the check-out/check-in process unit 
19 reads the specified content from the music data 
stored in the internal data storage unit 15, converts it to 
the copy format, and writes the converted music data in 
the external storage medium 7. When receiving the con- 
20 trol signal 32 for starting check-in, the check-out/check- 
in unit 19 deletes the music data copied to the external 
storage medium 7. 

[0051] The check-out/check-in unit 19 also reads 
the storage medium identifier 33 from the external stor- 
es age medium 7, and outputs it to the control unit 1 7. The 
control unit 17 records the received storage medium 
identifier 33 in the copyright management table 1 6 after 
check-out. The control unit 17 also determines before 
check-in whether check-in can be performed or not, 
30 depending on whether the received storage medium 
identifier 33 has been recorded in the copyright man- 
agement table 1 6 or not 

[0052] When receiving the control signal 32 for 
warning display, the display unit 21 generates a warning 
35 screen, and displays the screen on a CRT or a liquid 
crystal display. 

[0053] The data conversion process that character- 
izes the data processing apparatus 1 is now described 
below. With reference to a flowchart shown in FIG. 7, 
40 the operation of the purchase process unit 13 is first 
described to clarify a condition for data conversion. 
[0054] The purchase process unit 13 first receives, 
from the input unit 10, the instruction 30 for purchasing 
the content (step S201). The instruction 30 for purchas- 
45 ing specifies the content identifier of the content to be 
purchased and its purchase condition. The purchase 
condition of the content is equal to the purchase condi- 
tion 52 shown in FIG. 4, including playback only, full pur- 
chase, test-listening, and others. Then, the purchase 
so process unit 13 communicates with the billing server 6 
to carry out payment for purchasing the specified con- 
tent under the specified purchase condition (step S202). 
The purchase process unit 13 carries out payment by 
referring to the billing information 43 for the specified 
55 content. The purchase process unit 1 3 then determines 
whether the purchase process has succeeded or not 
(step S203). For example, in step S202, the purchase 
process unit 13 sends, to the billing server 6, informa- 
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tion that the user agrees to pay for the specified content 
under the specified purchase condition. Then, in step 
S203, by receiving the information from the billing 
server 6 for confirming payment, the purchase process 
unit 13 determines whether payment has succeeded or 
not Note that the manner of payment carried out by the 
purchase process unit 13 is not limited to the above. 
[0055] if the purchase process has succeeded, the 
purchase process unit 13 further determines whether 
the specified content is stored in the distributed data 
storage unit 11 or not (step S204). if the content is not 
stored, the purchase process unit 13 requests the distri- 
bution server 5 to distribute the music data including the 
content (step S205). After the specified content is 
stored in the distributed data storage unit 11, the pur- 
chase process unit 13 outputs the control signal 31 for 
data conversion to the data conversion unit 14 (step 
S206). The data conversion unit 14 converts the music 
data in the distribution format stored in the distributed 
data storage unit 11 into the internal format. The con- 
verted music data is stored in the internal data storage 
unit 15. 

[0056] If the purchase process has failed in step 
S203 the purchase process unit 13 outputs a control 
signal (not shown) for notifying that the purchase proc- 
ess has failed to the display unit 21 (step S207). Receiv- 
ing this control signal, the display unit 21 displays a 
warning screen indicating that the purchase process 
has failed. Note that the purchase process fails when 
the specified content is not found or cannot be pur- 
chased under the specified purchase condition, or the 
amount of payment is insufficient, for example. 
[0057] As stated above, data conversion is made in 
the data processing apparatus when the purchase proc- 
ess has succeeded, that is, when the specified content 
has been purchased under the specified purchase con- 
dition. 

[0058] Next, the effect of the data processing appa- 
ratus 1 according to the present embodiment is now 
described. FIG. 8 is a diagram showing how the music 
data is distributed from a plurality of providers to the 
data processing apparatus. The distributed music data 
each includes one or more contents 42 and billing infor- 
mation 43, and has a format unique to each provider. Of 
the distributed music data items, the navigation informa- 
tion 41 and the content 42 cannot be dispensed with for 
playback or other processes. On the other hand, the bill- 
ing information 43 is required only for the purchase 
process, but not for playback or others. 
[0059] For this reason, the distribution-format music 
data is converted into the internal-format music data by 
separating the billing information 43 from the distribu- 
tion-format music data, thereby enabling the following 
processes to be carried out through a uniform proce- 
dure, irrespective of the billing method of the music 
data. 

[0060] Further, the decryption key 54 for decrypting 
the encrypted content 42 is extracted from the billing 



information 43, and then stored in the copyright man- 
agement table 16. In this way, total management of the 
decryption key 54 enables music data decryption with a 
uniform procedure, irrespective of the distribution 
5 method of the decryption key. 

[0061] Still further, the internal format is identical to 
the distribution format without the billing information 43. 
Therefore, data conversion can be made without 
decryption of encrypted data and then encryption 
10 thereof. This makes the process in the data conversion 
unit 14 simple, and the processing speed of the data 
processing apparatus becomes improved. 
[0062] Still further, the billing information is sepa- 
rated from the music data in the distribution format after 
is the data conversion. Therefore, the amount of data in 
the data processing apparatus 1 can be reduced for the 
billing information 43. This method is quite effective if 
the billing information 43 is large in size for a compli- 
cated billing process. 
20 [0063] In the present embodiment, the copynght 
information of the music data is stored in the copyright 
management table 16. Alternatively, each row in the 
copyright management table 1 6 shown in FIG. 5 may be 
added to each package, thereby allowing copyright 
25 management by package. Moreover, of the items 
included in the copyright management table 16, the 
number of playbacks 55, the number of check-outs 56, 
and the check-out destination Information 57 may be 
managed together in a separate table. In this way, the 
30 items that are set only once and the items that are 
updated every time data conversion is performed may 
be separately managed using different tables, thereby 
improving data security. 

[0064] Furthermore, in the present embodiment, 
35 the distribution-format music data and the internal-for- 
mat music data are separately stored in different data 
storage units. Alternatively, the music data of these two 
types may be stored in a single data storage unit. 



40 (Second Embodiment) 

[0065] FIG. 9 is a block diagram showing the struc- 
ture of a data processing apparatus 2 according to the 
second embodiment of the present invention. The data 

45 processing apparatus 2 shown in FIG. 9 includes the 
input unit 10, the distributed data storage unit 11, the 
purchase management table 12, the purchase process 
unit 13, a data conversion unit 22, the internal data stor- 
age unit 15, the copyright management table 16, the 

so control unit 17, the playback unit 18, the check- 
out/check-in unit 19, the display unit 21 , and an external 
storage medium detection unit 23. The data processing 
apparatus 2 is used in the same music distribution sys- 
tem as that for the data processing apparatus 1 accord- 

55 ing to the first embodiment. The data processing 
apparatus 2 is characterized by converting distributed 
music data into an Internal format based on the type of 
the detected external storage medium. The compo- 



8 



15 



EP 1 081 574 A1 



16 



nents in the second embodiment identical to those in 
the first embodiment are provided with the same refer- 
ence numerals, and their description is omitted herein. 
[0066] The external storage medium 7 of various 
types such as DVD-RAM and a memory card can be 
connected to the data processing apparatus 2. There- 
fore, for check-out, the music data Is required to be con- 
verted into a copy format specified for each type of the 
external storage medium. In expectation of later conver- 
sion to a copy format, the data processing apparatus 2 
converts music data in the distribution format into the 
one in the internal format based on the type of the exter- 
nal storage medium 7. 

[0067] The external storage medium detection unit 
23 detects the type of the external storage medium 7, 
and outputs a detection signal 35 indicating the 
detected type to the data conversion unit 22. Based on 
the detection signal 35, the data conversion unit 22 con- 
verts the music data stored in the distributed data stor- 
age unit 1 1 into the internal format predetermined for 
each type of the external storage medium 7. 
[0068] FIG. 1 0 is a flowchart showing the operation 
of the data conversion unit 22. When receiving the con- 
trol signal Indicating data conversion (step S301). the 
data conversion unit 22 carries out the following proc- 
esses (steps S302 to S306) on the music data stored in 
the distributed data storage unit 1 1 based on the detec- 
tion signal 35. 

[0069] When receiving the detection signal 35 indi- 
cating that a DVD drive is connected (step S302), the 
data conversion unit 22 converts the music data into an 
internal format for DVD-RAM (step S303). When receiv- 
ing the detection signal 35 indicating that a memory 
adaptor is connected (step S304), the data conversion 
unit 22 converts the music data into an internal format 
for memory card (step S305). When receiving other- 
wise, the data conversion unit 22 converts the music 
data into a general internal format as shown in FIG. 3b 
(step S306). 

[0070] The data conversion unit 22 converts the 
music data into the internal format based on the type of 
the external storage medium 7 with the following proce- 
dure. FIG. 11 is a flowchart showing a process for con- 
version into the internal format for DVD-RAM. The 
process shown In FIG. 1 1 corresponds to the process in 
step S303 of the flowchart shown in FIG. 10. 
[0071] The data conversion unit 22 first copies the 
header 40 and the navigation information 41 included in 
the distribution format (step S401), and Initializes a var- 
iable I to 1 (step S402). Then, the data conversion unit 
22 carries out the processes from steps S403 through 
S407 for each content 42. The data conversion unit 22 
reads an attribute of an l-th content from the header 40 
(step S403). Based on the read attribute, the data con- 
version unit 22 determines whether the l-th content is to 
be copied to the DVD-RAM disk or not (step S404), and 
If yes, copies the l-th content to the external storage 
medium 7 (step S405). Then, the data conversion unit 



22 increments the variable I by 1 (step S406). If the var- 
iable I is not greater than the number of contents, the 
procedure returns to step S403 (step S407). 
[0072] In the flowcharts shown In FIGS. 10 and 1 1 , 

5 the data conversion process for the external storage 
media of certain types is shown. If the external storage 
medium of another type is connected to the data 
processing apparatus 2, a similar process Is added to 
each flowchart 

10 [0073] The control unit 1 7 manages the internal-for- 
mat music data using a package management table 
shown in FIG. 12. The package management table 
shown in FIG. 12 includes a package identifier 60, the 
number of files 61 , a file name 62, and a file type 63. 

is Each row in FIG. 12 corresponds to one package. 

[0074] The package identifier 60 is used for identify- 
ing each package. However, if the header is changed at 
conversion from the distribution format to the internal 
format, a new package identifier is assigned to the pack- 

20 age. The number of files 61 represents the number of 
files Included in the package, and the file name 62 rep- 
resents the name of each file. The file type 63 repre- 
sents an attribute of the file included in the package. A 
file type "distributed" indicates that the file is a distrib- 

25 uted one, while a file type "created" indicates that the 
file was created by the user. 

[0075] Next, the effect of the data processing appa- 
ratus 2 according to the present embodiment is 
described. FIGS. 13a, 13b, and 13c are diagrams show- 

30 ing the music data in the distribution format, in the inter- 
nal format, and in the copy format, respectively. Music 
data in the distribution format shown in FIG. 13a 
includes audio contents 42-1 and 42-2 and an image 
content 42-3. It is assumed herein that, of these con- 

35 tents, only the audio content 42-2 can be checked out to 
the external storage medium 7. In this case, music data 
in the copy format shown in FIG. 13c includes only the 
content 42-2. 

[0076] In expectation of later conversion into the 

40 copy format, the data processing apparatus 2 converts 
the music data from the distribution format to the inter- 
nal format shown in FIG. 13b for storage. The music 
data in the internal format includes only the audio con- 
tent 42-2 that can be checked out to the external stor- 

45 age medium 7. 

[0077] As stated above, by converting the distrib- 
uted music data into the internal format suitable for the 
type of the external storage medium 7, the amount of 
data in the data processing apparatus 2 can be 

so reduced. The content 42 is large in the amount of data 
because of audio and images compressed therein. 
Therefore, by storing only the content that can be 
checked out later, the amount of data can be signifi- 
cantly reduced. 

55 [0078] Furthermore, the distributed music data may 
include a plurality of contents obtained by applying a 
plurality of compression methods to a single original 
data. FIG. 14 shows an example of such music data. It 
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is assumed in FIG. 14 that the audio contents 42-1 and 
42-2 have been obtained by applying two compression 
methods to a single original data. In this case, the navi- 
gation data includes content selection data 46 indicating 
that one content can be selected from a plurality of con- 
tents. 

[0079] When such music data is distributed, the 
data conversion unit 22 selects the contents that can be 
checked out to the connected external storage medium 
from the plurality of contents. The music data in the 
internal format includes only the selected contents. For 
example, if the external storage medium is a memory 
card, the music data in the internal format includes only 
the contents that can be checked out to the memory 
card. By selecting and storing the contents in the above 
described manner, the amount of data stored in the 
internal data storage unit 15 can be reduced. 
[0080] Still further, the distributed music data may 
include a plurality pieces of navigation information 41 
based on each type of the external storage medium. 
Also in this case, the navigation information suitable for 
the connected external storage medium is selected 
from the plurality pieces of navigation information 41, 
and only the selected navigation information is included 
in the music data in the internal format Here, the navi- 
gation information may include a plurality of programs 
supporting the type of the data processing apparatus or 
the portable music player. Moreover, if the music data 
includes a plurality of contents supporting a plurality of 
languages, the contents in the specified language are 
selected. 

[0081] As stated above, even if the music data 
includes a plurality of contents or a plurality pieces of 
navigation information, the distributed music data is 
converted into the internal format based on the type of 
the external storage medium, thereby enabling reduc- 
tion in stored data amount. 

[0082] In the present embodiment, the music data 
is copied to DVD-RAM or a memory card. If the copy- 
righted data is a game software, the type of a game 
machine is specified, and then data is copied to a mem- 
ory card for the game machine, etc. 

(Third Embodiment) 



[0083] FIG. 15 is a block diagram showing the 
structure of a data processing apparatus 3 according to 
the third embodiment of the present invention. The data 
processing apparatus 3 shown in FIG. 15 includes the 
input unit 10, the distributed data storage unit 11, the 
purchase management table 12, the purchase process 
unit 13, the data conversion unit 22, the internal data 
storage unit 1 5, the copyright management table 1 6, the 
control unit 17, the playback unit 18, the check- 
out/check-in unit 19, the display unit 21, and an external 
storage medium specifying unit 24. The data processing 
apparatus 3 Is used in the same music distribution sys- 
tem as that for the data processing apparatuses accord- 



ing to the first and second embodiments. The data 
processing apparatus 3 is characterized by converting 
distributed music data into an internal format based on 
the type of the specified external storage medium. The 
5 components in the third embodiment identical to those 
in the second embodiment are provided with the same 
reference numerals, and their description is omitted 
herein. 

[0084] In the data processing apparatus 3, the user 
io specifies the type of the external storage medium 7 
through the input unit 10. The user can specify not only 
the type of the external storage medium being con- 
nected at that moment, but also the type of the external 
storage medium that will be later connected. When the 
is user specifies the type of the external storage medium, 
the display unit 21 displays a screen as shown in FIG. 
1 6. On this screen, any one of DVD-RAM and a memory 
card can be specified as the external storage medium. 
The screen shows that the memory, card is specified at 
20 this moment. Through this screen, the user can specify 
the type of the external storage medium to which the 
music data is checked out. 

[0085] Referring back to FIG. 15, when receiving 
the instruction 30 for specifying the external storage 
25 medium 7 from the input unit 10, the external storage 
medium specifying unit 24 stores the type of the speci- 
fied external storage medium. The external storage 
medium specifying unit 24 then provides a specifying 
signal 36 indicating the stored type of the external stor- 
30 age medium to the data conversion unit 22. 

[0086] Similarly to the second embodiment, the 
data conversion unit 22 operates according to a flow- 
chart shown in FIG. 17. Based on the specifying signal 
36, the data conversion unit 22 converts the music data 
35 stored in the distributed data storage unit 11 into the 
Internal format predetermined for each specified type of 
the external storage medium. The flowchart shown in 
FIG. 1 7 is similar to that shown in FIG. 10, and therefore 
its description is omitted herein. 
40 [0087] Next, the effect of the data processing appa- 
ratus 3 according to the present embodiment is 
described. The music data in the internal format in the 
data processing apparatus 3 Includes only the content 
that can be checked out to the specified external stor- 
45 age medium. Therefore, similarly to the second embod- 
iment, the amount of data stored can be reduced. 
[0088] In addition, the user can also specify the 
type of the external storage medium that will be later 
connected. Therefore, it is possible to convert the music 
so data to comply with such external storage medium. 
Thus, with the user specifying an appropriate check-out 
destination, the amount of data to be stored can be fur- 
ther reduced. 

[0089] Note that the data processing apparatuses 
55 according to the first to third embodiments can be 
achieved by combining a computer and a program oper- 
able on the computer. The data processing apparatus of 
the present invention can be realized by recording the 
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program on a recording medium typified by a floppy disk 
and installing the program in an arbitrary computer sys- 
tem. 

(Fourth Embodiment) 

[0090] As the fourth embodiment, as a specific 
example of copyrighted data as mentioned in the first to 
third embodiments, a content distribution format called 
SDAF (Secure Digital Audio Format) is described below. 
Referring to FIGS. 18 to 39, details on the SDAF is first 
described, and then referring to FIGS. 40 to 45, how to 
use the SDAF is described. 

[0091] The content distribution format (SDAF) 
according to the present embodiment is used for 
describing multimedia contents that include audio, 
images, video, text, and file data. The multimedia con- 
tents described with SDAF are herein called an SDAF 
title. Presentation data each comprising the SDAF title 
is herein called a content element (hereinafter abbrevi- 
ated as CEL). Each CEL is assigned a CEL identifier 
that is unique in the SDAF title (hereinafter abbreviated 
as CELJD). 

[0092] The SDAF title is distributed as being split 
into units called SDAF packages. Each SDAF package 
is assigned a package identifier that is unique in the 
entire distribution system. FIG. 18 is a diagram showing 
an example of the SDAF package. As shown In FIG. 18, 
an SDAF title 2000 is composed of a plurality of SDAF 
packages. Each package 2001 is composed of a header 
2011, navigation data 2012, a plurality of CELs 2013, 
and an offer 201 4. 

[0093] The header 201 1 includes information such 
as location, size, and attribute of each data in the pack- 
age. Such information defines the package structure. 
The navigation data 2012 is playback control informa- 
tion specifying the operation of the player in playing 
back the SDAF title. From the navigation data 2012, a 
CEL included in the package to which the navigation 
data belong or in other packages is referred to. The CEL 
2013 is obtained by encrypting each presentation data 
composing the SDAF title, and more specifically, by 
encrypting audio, images, video, text, or file data. A pair 
of a decryption key for decrypting the CEL 2013 and 
CELJD is called a key pair. The offer*2014 includes a 
plurality of key pairs, and purchase rules describing the 
purchase price and available period for each key pair. 
[0094] FIGS. 19a to 19c are diagrams showing 
three types of SDAF packages. A full package 2001 
shown in FIG. 19c includes, similarly to FIG. 18, a 
header 201 1 , navigation data 2012, a plurality of CELs 
2013, and an offer 2014. An offer package 2002 shown 
in FIG. 19a includes the header 2011, the navigation 
data 2012, and the offer 2014, but does not include any 
CEL 2013. A CEL package 2003 shown in FIG. 19b 
includes the header 2011 and the plurality of CELs 
2013. Since the navigation data 2012 is required for 
playing back the SDAF title, the full package 2001 and 



20 

the offer package 2002 can be played back alone, but 
the CEL package 2003 cannot 

[0095] The CEL package is used for splitting the 
SDAF title according to the distribution channel. For 

5 example, when distributed by using a CD-ROM, the 
SDAF title is recorded as a full package in the CD-ROM. 
On the other hand, when distributed through the Inter- 
net, the SDAF title is split into one full package and a 
plurality of CEL packages for distribution. For example, 

to the SDAF title is split into one full package Including an 
audio CEL and a plurality of CEL packages including a 
video CEL that is referred to from the full package for 
distribution. 

[0096] Further, as shown in FIG. 20, the SDAF title 
15 may be split into a plurality of SDAF packages by tracks. 
In package division as shown in FIG. 20, an SDAF title 
2020 including audio data for five tracks is split into 
three packages 2021 to 2023. The first to third pack- 
ages 2021 to 2023 have package names Single 1, 
20 Single2, and album, respectively. The first and second 
packages 2021 and 2022 both include an audio CEL for 
one track and navigation data for controlling playback of 
the CEL. The third package 2023 includes an audio 
CEL for three tracks and navigation data for controlling 
25 playback of all audio CELs Included in the first to third 
packages 2021 to 2023. As such, by dividing the SDAF 
title into a plurality of SDAF packages, it is possible to 
make each data size smaller and easily handle each 
data. 

30 [0097] The header, offer, navigation data, and CEL, 
which compose the SDAF package, are described in 
this order below. 

[0098] The header 201 1 is first described. Here, an 
SDAF package shown in FIG. 21 is taken as an exam- 

35 pie, and a header 2031 of an SDAF package 2030 is 
described. In the SDAF package 2030, it is herein 
assumed that the size of navigation data 2032 and the 
size of an offer 2034 are 400H each, in hexadecimal 
notation. This package includes three CELs 2033, and 

40 the types thereof are, from first, audio, image, and file. It 
is assumed herein that the sizes of these CELs are, 
from first, 400000H, 18000H. and 8000H in hexadeci- 
mal notation. 

[0099] FIG. 22 is a diagram showing the structure of 
45 the header 2031. In the header 2031 , data as described 
below Is sequentially stored, and the size of the header 
is BCH in hexadecimal notation. Note that the structure 
of the header 2031 can be described in the C++ lan- 
guage as shown in FIGS. 23 and 24. FIGS. 23 and 24 
so are a diagram showing a sequential source code as 
being split into two, and before division, a source code 
2062 shown in FIG. 24 follows a source code 2061 
shown in FIG. 23. 

[0100] At the start of the header 2031, a magic 
55 number 2041 (4 bytes) indicating that the file is in the 
SDAF format is stored. The value of the magic number 
2041 is a character string "SDAF. Then, a version 
number 2042 (4 bytes) of the SDAF is stored. Then, a 



EP 1 081 574 A1 



11 



21 



EP 1 081 574 A1 



22 



package ID 2043 (1 6 bytes) and a package size 2044 (4 
bytes) are stored. Then, navigation data location infor- 
mation 2045 (SDAF J.OCATI O N__N AV In FIG. 23), offer 
location Information 2046 (SDAFJ_OCATION_OFFER 
in FIG. 23), and the number of CELs in the package 
2047 are stored. Then, CEL information 2048 
(SDAF_LOCATlON_CEL in FIG. 24) for each CEL is 
stored. Lastly, a CEL attribute table 2049 indicating an 
attribute of each CEL is stored. 
[0101] The navigation data location information 
2045 indicates the location and size of the navigation 
data 2032. The offer location information 2046 indicates 
the location and size of the offer 2034. These two pieces 
of information are both composed of an offset (4 bytes) 
from the start of the SDAF package and each size (4 
bytes) thereof . 

[0102] The CEL information 2048 is composed of a 
CELJD 2051 (16 bytes), a CEL type 2052 (2 bytes), a 
CEL encryption type 2053 (2 bytes), a CEL data loca- 
tion information 2054, and a CEL attribute table location 
information 2055. The CELJD 2051 is a content ele- 
ment identifier that is unique in the SDAF title. The CEL 
type 2052 takes any value of audio, image, video, text, 
and file. The CEL encryption type 2053 indicates an 
algorithm used for encrypting the CEL. The CEL data 
location information 2054 and CEL attribute table loca- 
tion information 2055 are both composed of an offset (4 
bytes) from the start of the SDAF package and each 
size (4 bytes) thereof. If the offset or size is 0, that 
means no data exists. 

[0103] The CEL attribute table 2049 is a list of 
attributes specified for each CEL type. An audio CEL 
attribute table (SAD F_ATTR_AU D IO in FIG. 24) 
includes at least CODEC, the number of quantized bits, 
sampling frequency, and the number of audio channels. 
An image CEL attribute table (SDAF_ATTR_GRAPHIC 
in FIG. 24) includes at least the height and width of the 
image and the encryption type. A video CEL attribute 
table includes at least the height and width of the video 
and the encryption type. A text attribute table includes at 
least the encryption type of the text, such as Unicode or 
music shift JIS (Japanese Industrial Standards). A file 
CEL attribute table includes at least the type of MIME 
(Multipurpose Internet Message Extension). 
[0104] The CEL attribute table 2049 is defined not 
as a fixed-length table but with a variable-length tag 
structure as shown in FIGS. 25a to 25c. If the tag struc- 
ture is used, a tag length and tag ID are stored preced- 
ing the data, as shown in FIG. 25a. For example, the 
image CEL attribute table is composed of a characteris- 
tic tag 2063 and an encryption type tag 2064. The table 
elements are specified by using the tag structure, 
thereby a new table element can be added to the data 
format or the data format can be changed only by add- 
ing a tag. The CEL attribute table is specified by using 
the tag structure with a great potential for expansion. 
[0105] Next, the offer 2014 is described. As stated 
above, the offer includes a plurality of key pairs and pur- 



chase rules for each key pair. Each key pair is com- 
posed of a decryption key for decrypting the CEL and a 
CELJD. FIG. 26 is a diagram showing the correspond- 
ence between the key pair and the CEL. As shown in 
5 FIG. 26, a key pair 2072 is composed of a decryption 
key 2073 and a CELJD 2074, and each key pair 2072 
is related to each CEL 2071 . The offer includes not only 
the key pair of the CEL included in the SDAF package 
but also all key pairs of the CELs included in the SDAF 
, o packages of the same SDAF title. In other words, when 
one SDAF title is spirt into a plurality of SDAF packages, 
only one SDAF package includes an offer, and this offer 
includes all key pairs of the CELs included in the SDAF 
title. 

15 [0106] The purchase rules are described by using a 
language for describing use conditions of the key pair, 
called right management language. The use conditions 
of the key pair include the date of purchase, use period, 
and whether a specific CEL or SDAF title has been pur- 
20 chased or not. The purchase rules are specified by 
using these use conditions, and thereby the same CEL 
can be sold at different prices depending on the condi- 

[01 07] Next, the navigation data 2012 is described. 
25 The navigation data is created by a content creator so 
that the user can use the CEL most effectively, defining 
the logic structure of the SDAF title. 
[0108] In SDAF, XML (extensible Markup Lan- 
guage), which is a tag description language in a text for- 
30 mat, is used for describing the navigation data. When 
the data structure Is described in XML, a tag structure in 
a text format is used. Therefore, data described in XML 
is redundant compared with binary data. Nevertheless, 
XML is adopted because of its excellent expandability. 
35 [01 09] To refer to the CEL from the navigation data, 
a CEL locator is used. The CEL locator is a concatena- 
tion of the package ID and CELJD taking '?' (question 
mark) as a delimiter. However, for the CEL included in 
the SDAF package that includes the navigation data, 
40 the package ID and the delimiter are omitted, and the 
CELJD becomes the CEL locator. The CEL locator can 
specify the CEL independently of the physical address 
of the CEL 

[011 0] FIG. 28 is a diagram showing how to refer to 
45 the CEL from the navigation data by using the CEL loca- 
tor. In FIG. 28, navigation data 2081 and presentation 
data 2082 are shown as an example. The presentation 
data 2082 includes an audio CEL 2083 encoded with 
MPEG2-AAC and an image CEL 2084 encoded with 
so JPEG. The package ID and CEI^ID of the audio CEL 
2083 are both 1 , while those of the image CEL 2084 are 
1 and 2, respectively. In this case, a CEL locator "1?r 
included in the navigation data 2081 indicates the audio 
CEL 2083 with its package ID "1" and CELJD "1". A 
55 CEL locator "1 ?2* indicates the image CEL 2084 with its 
package ID "1" and CELJD m 2T. As known from this 
example, only a change in the package ID of the CEL 
locator after creation of the SDAF title can cause a 
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change In the structure of the SDAF package. There- 
fore, it is possible to structure the SDAF title as a single 
package or split the SDAF title into a plurality of SDAF 
packages. 

[0111] FIGS. 29 and 30 are diagrams showing the 
structure of the navigation data based on the following 
representation manner. Each rectangle represents an 
element of the navigation data. An arrow drawn from an 
element A to an element B indicates that the element A 
includes the element B as a descendant element Each 
mark provided at the start of each arrow indicates as fol- 
lows: * indicates that the element includes 0 or more 
descendant elements; + indicates that the element 
includes 1 or more descendant elements; and ? indi- 
cates that the element includes 0 or 1 descendant ele- 
ment. If the element A includes an item P without any 
arrow, that means the element A has the item P as an 
attribute. Underlined items represent CEL locators. 
PCDATA represents a character string composed of 
characters included in a predetermined character set 
This representation specifies a hierarchical structure 
with a TITLE element as a root. 

[0112] A TITLE element 2101 describes shipping 
information of the SDAF title. This element has three 
attributes: UPC, VERSION, and LANGUAGE. The UPC 
attribute describes a UPC (Universal Product Code), 
which is the international standards of product codes. 
The VERSION attribute describes the version number 
of the SDAF navigation structure. The LANGUAGE 
attribute describes the type of language according to 
ISO 639. Its default value is "en" indicating English. 
[0113] A METADATA element 21 02 describes infor- 
mation such as genre of a PLAYLIST or TRACK ele- 
ment. The METADATA element has a TYPE attribute. 
The TYPE attribute describes the type of the META- 
DATA element 

[0114] An ASSOC element 2103 describes refer- 
ence information to a CEL included in other SDAF titles. 
This element has a REF attribute. The REF attribute 
describes the CEL locator. 

[0115] A URL element 2104 describes the URL 
(Uniform Resource Locator). This element has two 
attributes: ID and TYPE. The ID attribute describes the 
identification number of this element The TYPE 
attribute describes the type of the URL element 
[0116] A PLAYLIST element 2105 describes a play- 
list, which is a basic unit for the SDAF title. The playlist 
corresponds to an album in the conventional package 
media, and is Included in all SDAF titles. The PLAYLIST 
element may include a MENU element, which is a menu 
for the playlist The PLAYLIST element has five 
attributes: NAME, ARTIST, PRODUCTID, THUBMNAI- 
LID, and ONSTART The NAME attribute describes the 
name of the playlist The PRODUCTID attribute 
describes information corresponding to a catalog code 
in a CD. The THUMBNAILID attribute describes the 
CEL locator of the Image CEL that Is typical in the play- 
list The ONSTART attribute describes the operation for 



playing back the playlist. If the ONSTART attribute Is 
"MENU", the player stops playing while displaying a 
playlist menu. If TRACK", the player starts playing back 
the first TRACK element Included in the PLAYLIST ele- 
5 ment All PLAYLIST elements have at least one TRACK 
element 2106. 

[0117] The TRACK element 2106 describes the 
track including one audio CEL. The TRACK element 
may include a track menu, slideshow, text, file, and oth- 

w ers. The TRACK element has seven attributes: ID, 
NAME, ARTIST, ISRC, AUDIOID, TSMID, and THUM- 
BAILID. The ID attribute describes the identification 
number that is unique in the SDAF title. The NAME 
attribute describes the name of the TRACK element. 

15 The ARTIST attribute describes the name of the artist. 
The ISRC attribute describes ISRC (International 
Standard Recording Code). The AUDIOID attribute 
describes the CEL locator of the audio CEL related to 
the TRACK element. The TSMID attribute describes the 

20 CEL locator of a time search map corresponding to the 
audio CEL The time search map will be described later. 
The THUMBNAILID attribute describes the CEL locator 
of the image CEL that is typical in the TRACK element 
[0118] A MARKER element 2107 describes a 

25 marker for use in finding the start in the TRACK ele- 
ment This element has two attributes: TIME and 
NAME. The TIME attribute describes the location of the 
marker in milliseconds. The NAME attribute describes 
the name of the marker. 

30 [0119] A SYNCSLIDESHOW element 2108 
describes a slideshow for displaying slides or menus by 
following display timing Information specified by a SYN- 
CMAP element 21 09. The SYNCSLIDESHOW element 
2108 has three attributes: ID, NAME, and TYPE. The ID 

55 attribute describes the Identification number that is 
unique in the SDAF title. The NAME attribute describes 
the name of the slideshow. The TYPE attribute 
describes the information category in the track, such as 
credits, lyrics, liner notes, biography, image collection, 

40 or promotion. 

[01 20] The SYNCMAP element 21 09 describes the 
display timing information for the slide or the menu 
specified in the SYNCSLIDESHOW element The SYN- 
CMAP element 2109 has three attributes: MENU ID, 

45 PLAY ID, and TIME. The MENUID attribute describes 
the identification number of the slide or menu to be dis- 
played. The PLAY ID attribute describes the index 
number for specifying a button to be set in a playback 
state on the menu. The TIME attribute describes the 

so display timing in milliseconds. 

[0121] A SLIDESHOW element 21 1 0 describes the 
slideshow for displaying slides or menus at predeter- 
mined display intervals. This element has four 
attributes: ID, NAME, TYPE, and INTERVAL. The ID 

55 attribute describes the identification number that is 
unique in the SDAF title. The NAME attribute describes 
the name of the slideshow. The TYPE attribute 
describes the information category in the track, such as 
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credits, lyrics, liner notes, biography, image collection, 
or promotion. The INTERVAL attribute describes the 
display interval of the slide or menu. 
[0122] A SYNCTEXT element 21 1 1 describes text 
information to be displayed with predetermined timing. 
The text information is described by using a SYNC- 
TEXTBLOCK element 21 12. Alternatively, the text infor- 
mation may be specified by referring to part of the text 
CEL. The SYNCTEXT element has four attributes: ID, 
TEXTID, REFID, and TYPE. The ID attribute describes 
the identification number that Is unique in the SDAF title. 
The TEXTID attribute describes the CEL locator of the 
text CEL. The REFID attribute describes the identifica- 
tion number of a TEXTREF element In the text CEL 
specified by the TEXTID attribute. The TEXTREF ele- 
ment will be described later. The TYPE attribute 
describes the information category in the track, such as 
credits, lyrics, liner notes, biography, image collection, 
or promotion. 

[0123] The SYNCTEXTBLOCK element 21 12 
describes the text information to be displayed with pre- 
determined timing. This element has a TIME attribute. 
The TIME attribute describes the display timing in milli- 
seconds. 

[0124] The TEXT element 21 13 describes text infor- 
mation. The text information is described in a text data 
format. Alternatively, the text information may be speci- 
fied by referring to part of the text CEL. The TEXT ele- 
ment has the same types of attributes as the 
SYNCTEXT element has. 

[0125] A VIDEO element 2114 describes any exist- 
ing video CEL. This element has three attributes: ID, 
VIDEOID, and TYPE. The ID attribute describes the 
identification number that is unique in the SDAF title. 
The VIDEOID attribute describes the CEL locator of the 
video CEL. The TYPE attribute describes the informa- 
tion category in the track, such as credits, lyrics, liner 
notes, biography, image collection, or promotion. 
[0126] A FILE element 21 15 describes any existing 
file CEL. This element has three attributes: ID, FILE ID, 
and TYPE. The ID attribute describes the identification 
number that is unique in the SDAF title. The FILEID 
attribute describes the CEL locator of the file CEL. The 
TYPE attribute describes the information category in 
the track, such as credits, lyrics, liner notes, biography, 
image collection, or promotion. 

[0127] A SLIDE element 2116 describes a slide. 
This element has three attributes: ID, NAME, and 
BACKGROUND ID. The ID attribute describes the iden- 
tification number that is unique in the SDAF title. The 
NAME attribute describes the name of the slide. The 
BACKGROUNDID attribute describes the CEL locator 
of the image CEL on a slide screen. 
[0128] A MENU element 2117 describes a menu. 
The menu has one or more onscreen buttons. The 
MENU element has four attributes: ID, NAME, BACK- 
GROUNDID, and SELECTID. The ID attribute describes 
the identification number that is unique in the SDAF title. 



The NAME attribute describes the name of the menu. 
The BACKGROUNDID attribute describes the CEL 
locator of the image CEL displayed on a menu screen. 
The SELECTID attribute describes the Index number for 

5 specifying a button to be set in a select state. 

[0129] A BUTTON element 2118 describes the 
onscreen buttons arranged on the menu screen. The 
BUTTON element Includes, as descendant elements, 
one or more pairs of TEXTBUTTON and COMMAND 

w elements or those of GRAPHICBUTTON and COM- 
MAND elements. The BUTTON element has seven 
attributes: INDEX, TAB, UP, DOWN, RIGHT, LEFT, and 
AUTOACTION. The INDEX attribute describes the 
Index number that is unique in the MENU element The 

15 TAB attribute describes the sequential number sequen- 
tially and circulatively provided for each of the buttons 
on the menu. The UP, DOWN, LEFT, and RIGHT 
attributes describe the index number of the selected 
destination button located upward, downward, leftward, 

20 and rightward, respectively, from the current button. The 
AUTOACTION attribute describes the flag indicating 
whether the state is automatically changed from select 
to active. 

[0130] A TEXTBUTTON element 2119 describes 

25 the onscreen button represented by text. This element 
has eleven attributes: X, Y, WIDTH, HEIGHT, FORN- 
TSIZE, NORMALCOLOR, SELECTCOLOR, ACTION- 
COLOR, PLAYINGCOLOR, TEXTID, and REFID. The 
X, Y, WIDTH, and HEIGHT attributes each describe the 

30 display location of the button using a coordinate system 
taking the upper-left corner of the menu as the origin. 
The FONTSI2E element describes the font size in 
points. The NORMALCOLOR, SELECTCOLOR, 
ACTIONCOLOR, and PLAYINGCOLOR attributes 

35 describe a display color In RGB format when the button 
state is normal, select, active, and playback, respec- 
tively. The TEXTID attribute describes the CEL locator 
of an external text CEL. The REFID attribute describes 
the identification number of the TEXTREF element in 

40 the text CEL specified by the TEXTID. 

[0131] A GRAPHICBUTTON element 2120 
describes the onscreen button represented as graphics. 
This element has eight attributes: X, Y, WIDTH, 
HEIGHT, NORMALID, SELECTID, ACTIONID, and 

45 PLAYING ID. The X, Y, WIDTH, and HEIGHT attributes 
each describe the display location of the button using a 
coordinate system taking the upper-left comer of the 
menu as the origin. The NORMALID, SELECTID, 
ACTIONID, and PLAYING ID attributes each describes 

so the CEL locator of the image CEL displayed when the 
button state is normal, select, active, and playback, 
respectively. 

[0132] A COMMAND element 2121 describes the 
navigation operation when the user presses one of the 
55 onscreen buttons. This element has two attributes: 
TYPE and TARGET. The TYPE attribute describes any 
one of SHOW, FUNCTION, GOTO, NEXT, and PREVI- 
OUS commands. The SHOW command is for displaying 
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the element specified by the TARGET attribute. The 
FUNCTION command is for executing the element 
specified by the TARGET attribute. This command is 
used while a playllst menu is being displayed. The 
GOTO command is for moving from the element cur- 
rently displayed to a specified brother element. The 
NEXT command is for moving from the element cur- 
rently displayed to the next brother element. The PRE- 
VIOUS element is for moving from the element currently 
displayed to the previous brother element. The TARGET 
attribute describes the parameter of the command 
specified by the TYPE attribute. If the SHOW command 
is specified, the TARGET attribute describes the identi- 
fication number of the element to be displayed. If the 
FUNCTION command is specified, the TARGET 
attribute describes the identification number of the ele- 
ment to be executed. If the GOTO command is speci- 
fied, the TARGET attribute describes the identification 
number of the brother element of the element currently 
displayed. 

[0133] The TEXTREF element describes text cate- 
gory information for use in referring from the navigation 
data to part of the text data stored in the text CEL. The 
text data included in the TEXTREF element is referred 
to by specifying the identification number of the TEX- 
TREF element from the navigation data. The TEXTREF 
attribute has an ID attribute. The ID attribute describes 
the identification number that is unique in the SDAF 
tittle. 

[0134] Next, the CEL 2013 is described. The CEL 
has five types: audio, image, video, text, and file. In 
SDAF, the data format and parameter are specified for 
each type of the CEL. 

[0135] The data included in the audio CEL is audio 
data encoded in compliance with MPEG2-AAC 
(Advanced Audio Coding) [Low Complexity Profile]. 
Note that MPEG2-AAC is specified in ISO/IEC 1381 8-7: 
1997(E) Information technology - Generic coding of 
moving pictures and associated audio information - 
Part7 Advanced Audio Coding (AAC). The bit stream 
encoded with MPEG2-AAC is assumed to be in the 
ADTS (Audio Data Transport Stream) format Further, 
parameters described in ISO/IEC 1 381 8-7 are 
restricted as shown in FIG. 31. Of these parameters, 
parameters other than sampling_frequency_index and 
channel_configuration are restricted due to selection of 
LC-profile specified by ISO/IEC 13818-7. Further, the 
average bit rate is 64 or 128 kbps. 
[0136] Data included in the image CEL is image 
data encoded in compliance with JPEG, MPEG-I frame, 
or PNG (Portable Network Graphics). FIGS. 32, 33, and 
34 are tables showing specification of JPEG, MPEG-I 
frame, and PNG, respectively. The specifications for the 
encryption algorithms applied to the image CEL are 
restricted as shown in these figures. 
[0137] Data included in the video CEL is video data 
encoded in compliance with MPEG2. FIG. 35 is a table 
showing the specification of MPEG 2. The specification 



for the encryption algorithm applied to the video CEL is 
restricted as shown in FIG. 35. 

[0138] Data included in the text CEL is PLAIN text 
or XML text in SDAF. The encryption type is Unicode or 

5 music shift J IS. 

[0139] As an example of the file CEL, a time search 
map CEL that includes a time search map as data is 
now described. The time search map is a table com- 
posed of address of an audio frame. FIG. 36 is a dia- 

io gram showing the structure of the time search map. As 
shown in FIG. 36, a time search map 2090 is composed 
of a header 2091 and a plurality of entries 2092. FIGS. 
37, 38a, and 38b are a table and diagrams showing the 
header 2091 in detail. As shown in FIGS. 37, 38a, and 

is 38b, the header 2091 includes playback duration 
between entries described in milliseconds and the total 
number of entries. FIG. 39 is a table showing each entry 
in detail. As shown in FIG. 39, each entry includes the 
address of the audio frame at its entry point. The first 

20 entry indicates the starting location of the audio frame 
included in the audio CEL. 

[0140] Note that in the present embodiment, 
MPEG2-AAC is used for compressing music data 
included in the audio CEL. Alternatively, MP3 (MPEG1 
25 Audio Layer 3), Dolby-AC3, or DTS (Digital Theater 
System) may be used. 

[0141] Next, with reference to FIGS. 40 to 45, how 
to use the SDAF is described. As stated above, the 
SDAF is a format for describing multimedia contents, 

30 and mainly used for music data distribution. The SDAF 
can be applied to various types of recording media, typ- 
ically hard disks, optical disks such as DVD-RAM, and 
semiconductor memory such as memory cards. 
[0142] In addition to music data distribution, the 

35 SDAF can be used in combination with the existing 
music data. For example, to be mentioned below, the 
SDAF can be used in combination with music data com- 
plying with the DVD-Audio standards. Similarly, the 
SDAF can be applied to other recording media such as 

40 DVD-Video, CD, Video-CD, and Photo CD. 

[0143] Music data complying with the DVD-Audio 
standards includes LPCM (Linear Pulse Code Modula- 
tion) audio contents and MPEG-I frame image contents. 
A player complying with the DVD-Audio standards dis- 

45 plays a menu screen for user's interactive operation. In 
the DVD-Audio standards, such menu screen is dis- 
played by superimposing a maximum of four-color sub 
video images onto a background image for display and 
providing a plurality of rectangular regions in the sub 

so video images. Such rectangular regions are called but- 
tons, and each button is assigned a command. How- 
ever, some restrictions are applied to the number of 
display colors and the shape of the button and therefore 
the content creator cannot freely design the menu 

55 screen. 

[0144] This problem can be solved by previously 
recording data of the menu screen described in the 
SDAF in a conventional DVD-Audio disk, and displaying 
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the menu screen using this data at playback. More spe- 
cifically, the DVD-Audio disk records multimedia con- 
tents described in the SDAF and a CEL redirector for 
referring from the SDAF to the original DVD-Audio con- 
tents. Hereinafter, a DVD-Audio disk with such data 
recorded thereon is called an extended DVD-Audio disk, 
and a player for playing back the extended DVD-Audio 
disk is called SDAF-compliant DVD-Audio player. 
[01 45] FIG. 40 is a diagram showing an example of 
the CEL redirectors that correspond to a single DVD- 
Audio disk. Each row indicates the CEL redirector for 
each content included in the original DVD-Audio disk. 
The CEL redirector includes a CELJD 2201 , file name 
2202, start address 2203, and end address 2204. The 
CEL ID 2201 is a content identifier that is unique in the 
disk.~The file name 2202 is a name of the file that 
includes each content. The start and end addresses 
2203 and 2204 are offset values Indicating the start 
location and end location, respectively, of each content 
in the file. The CEL redirector is recorded in a file named 
DVDA.MAP, for example, in an SDAF directory provided 
in the ROM area of the extended DVD-Audio disk. 
[0146] All various playback control functions such 
as audio playback order control, slideshow image play- 
back, and a menu function defined by the DVD-Audio 
standards can be described using the SDAF navigation 
data. For example, the menu function can be realized by 
superimposing JPEG button images having any number 
of colors and shape onto an MPEG-I frame background 
image for display and relating each button region to a 
command. 

[0147] When playback control information included 
in the DVD-Audio disk is converted into SDAF naviga- 
tion data, information indicating a content is converted 
into the CELJD by using the CEL redirector. The menu 
screen is converted Into JPEG button images. The 
obtained images are arranged at locations so as to be 
superimposed onto the background image. The naviga- 
tion data and button images as obtained In the above 
described manner are stored in a single SDAF package, 
and recorded in a file named SDAF.SDP, for example, in 
an SDAF directory provided in the ROM region of the 
extended DVD-Audio disk. The method of playing back 
the extended DVD-Audio disk will be described later. 
[0148] Next, an SDAF player for playing back multi- 
media contents described with SDAF is described 
below. The SDAF player plays back distributed music 
data in the following manner. First, the player searches 
for the package IDs and navigation information to collect 
the CELJDs of the CELs required for playback. The 
player searches, purchase database using sets of the 
collected package ID and CELJD to determine whether 
each CEL has been purchased or not. If any CEL not 
yet purchased is found, the player analyzes the 
encoded offer, and pays a predetermined price through 
the existing electronic distribution system. After pur- 
chasing, the key pair stored in the offer is stored in the 
purchase database. If determining that the SDAF pack- 



age required for playback Is not found in the player, the 
player sends out the package ID to the data distribution 
apparatus. The data distribution apparatus distributes 
an SDAF package with the received package ID to the 
5 player. After purchasing all CELs required for playback, 
the player decrypts the CELs using the key pairs stored 
in the purchase database for playback. At this time, the 
player interprets the navigation data for playback con- 
trol. 

w [01 49] The SDAF title is distributed to the player as 
being split into one or more SDAF packages. FIGS. 41a 
to 41 c are diagrams showing examples how to distribute 
the SDAF packages. In a distribution method as shown 
in FIG. 41 a, a package 2301 includes only an audio 
is content, while a package 2302 includes only an image 
or video graphic content Moreover, from the package 
2302, the audio content included In the package 2301 is 
referred to. Therefore, the user who purchased only the 
package 2301 can play back only the audio content. 
20 The user who purchased the package 2302 in addition 
to the package 2301 can play back the graphic content 
together with the audio content. As such, the SDAF title 
may be specified by adding a CEL to the existing track. 
[0150] In a distribution method as shown In FIG. 
25 41b, a package 2303 Includes a plurality of audio con- 
tents and graphic contents. As such, a single package 
may include all CELs included in the SDAF title. 
[0151] In a distribution method as shown in FIG. 
41c, a single SDAF title is split into packages 2304, 
30 2305, and 2306 for distribution. The package 2305 
includes a content for Track #1 , while the package 2306 
includes a content for Track #2. In this distribution 
method, it is possible to select either one of the pack- 
ages 2305 and 2306 for distribution. 
35 [0152] Moreover, in the player, a new SDAF pack- 
age including a content owned by the user may be cre- 
ated. FIGS. 42a to 42c are diagrams showing examples 
how to create SDAF packages. In FIGS. 42a to 42c, a 
user package is an SDAF package created by the user, 
40 while a purchased package is a distributed SDAF pack- 
age. Contents surrounded by a thick line are owned by 
the user It is assumed herein that the user owns data 
read from a CD, that is, an audio content ripped from the 
CD, and a graphic content created by himself/herself. 
45 [0153] As shown in FIG. 42a, the user may create a 
package 2401 including the audio content owned by 
himself/herself. Furthermore, as shown in FIG. 42b, the 
user may create a package 2402 including the audio 
and graphic contents owned by himself/herself. Still fur- 
so ther, as shown in FIG. 42c, the user may create a pack- 
age 2404 from which the audio content included in the 
purchased package 2403 is referred to. If the package 
2404 is played back, the audio content included In the 
purchased package and the graphic content owned by 
55 the user are played back. Therefore, the image included 
in the purchased package can be changed to the image 
created by the user, or a new Image created by the user 
can be added to the purchased package. 
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[01 54] Next, the SDAF-compliant DVD-Audio player 
for playing back the extended DVD-Audio disk is 
described. The player controls playback operation by 
following the navigation data described with SDAF 
Instead of the original playback control Information com- 
plying with the DVD-Audio standards. The player reads 
the navigation data and the CEL locator from the 
extended DVD-Audio disk, and operates by following 
the read navigation data. If the original audio content or 
image content is referred to from the navigation data, 
the player refers to the CEL locator to obtain Information 
about the location in which the content is stored, and 
plays back the content. The player reads the back- 
ground image from the DVD-Audio region on the disk 
and the button images from the SDAF data, and com- 
bines them to display the menu screen. 
[0155] As such, with the use of the extended DVD- 
Audio disk, the existing DVD-Audio player can carry out 
conventional playback, while the SDAF-compliant DVD- 
Audio player can display the menu screen by using the 
navigation data described with SDAF. 
[0156] In the above description, the SDAF package 
and CEL redirector are stored in the disk. Alternatively, 
such data may be downloaded through a network to the 
player. This method can be applied to CDS and DVD 
disks that have already been sold to the user. Further- 
more, with this method, the CELs that are accessible 
through a communication network can be referred to by 
using the URL. 

[0157] Next, a data conversion apparatus for copy- 
ing multimedia contents specified In SDAF to an exter- 
nal storage medium for portable music players is 
described. Here, the portable music player is structured 
by using semiconductor memory as an external storage 
medium, and characterized by Its small size, light 
weight, and capability of writing data therein at high 
speed. The portable music player includes, as shown in 
FIG. 43, a liquid crystal display 2501 capable of display- 
ing text, a control panel 2502 for controlling audio play- 
back, and a headphone 2503 for audio output 
Furthermore, a memory card 2500 for storing audio 
data can be removably attached to the portable music 
player. The portable music player plays back audio con- 
tents complying with MPEG2-AAC, and also displays 
text information. However, the data recording format of 
the memory card is not SDAF, but a unique format. 
[0158] FIG. 44 is a block diagram showing the 
structure of the data conversion apparatus for convert- 
ing contents recorded on an extended DVD-Audio disk 
into a predetermined format, and writing the converted 
contents in a memory card for portable music players. In 
FIG. 44, It is assumed that an LPCM-format audio con- 
tent, an Image content In MPEG-I frame format, play- 
back control information described with SDAF, and 
additional text information are recorded in a disk 2601 . 
[0159] In the data conversion apparatus shown in 
FIG. 44, a data read unit 2602 reads the playback con- 
trol information from the disk 2601, and provides the 



same to a playback control information analyzing unit 
2603. The playback control information analyzing unit 
2603 analyzes the read playback control information to 
examine whetherthe content recorded on the disk 2601 

5 can be played back or requires conversion. 

[0160] Next, the data read unit 2602 sequentially 
reads, from the disk 2601 , contents that can be played 
back by the portable music player, and provides the 
read contents to a data conversion unit 2605. At this 

io time, contents that cannot be played back by the porta- 
ble music player is not read. The data conversion unit 
2605 converts the read contents according to the type 
of a memory card 2500. For example, text information 
that can be directly played back by the portable music 

15 player such as titles is not converted. On the other hand, 
LPCM-format audio contents are converted into 
MPEG2-AAC format so that the portable music player 
can play back the contents. 

[01 61 ] The playback control information conversion 
20 unit 2604 generates playback control information for the 
portable music player based on the playback control 
information analyzed by the playback control informa- 
tion analyzing unit 2603. A data write unit 2606 writes 
the playback control information generated by the play- 
25 back control information conversion unit 2604 and the 
contents converted by the data conversion unit 2605 in 
the memory card 2500. 

[01 62] Note that, the data conversion unit shown in 
FIG. 44 may convert arbitrary contents other than audio 

30 contents into a predetermined format and write the con- 
verted contents In the memory card 2500. Furthermore, 
the data recording format of the memory card may be 
an arbitrary format other than SDAF. Still further, for 
supporting a plurality of external storage media, the 

35 data conversion apparatus may include the data conver- 
sion unit, playback control information conversion unit, 
and data write unit for each external storage medium. 
[0163] Moreover, if no navigation data described 
with SDAF is recorded on the disk 2601 , as shown in 

40 FIG. 45, lacking data may be obtained through a com- 
munication network. In FIG. 45, it is assumed that an 
identification number is recorded in the disk 2601. For 
example, the identification number of a music CD is a 
catalog code, ISRC code, and others. 

45 [0164] The data read unit 2602 reads the identifica- 
tion number of the disk, and provides the same to a 
communication unit 2607. The communication unit 
2607 communicates with a content information server 
261 1 through a communication network 261 0. The com- 

so munlcation unit 2607 may access to the content infor- 
mation server 261 1 through the Internet, or may directly 
access the content information server 261 1 through a 
telephone circuit. The content Information server 261 1 
stores the lacking data in relation to the identification 

55 number, and in response to a request from a data con- 
version apparatus, sends the lacking data to the data 
conversion apparatus. After receiving the lacking data, 
the data conversion apparatus carries out the same 



17 



33 



EP 1 081 574 A1 



34 



operation as the data conversion apparatus as shown In 
FIG. 44. 

[0165] As stated above, the content distribution for- 
mat SDAF according to the present embodiment is a 
format for describing multimedia contents, and mainly 
used for music data distribution. Also, using the SDAF in 
combination with the existing music data can extend the 
function of the existing music data. 
[0166] Note that, as known from the comparison 
between FIGS. 3 and 18, the correlation between the 
music data described in the first to third embodiments 
and the SDAF according to the present embodiment is 
as follows. That is, the header 40 shown in FIG. 3 corre- 
sponds to the header 2011 shown in FIG. 18. The navi- 
gation information 41 shown in FIG. 3 corresponds to 
the navigation data 2012 shown in FIG. 18. The content 
42 shown in FIG. 3 corresponds to the CEL 201 3 shown 
in FIG. 18. The billing information 43 shown in FIG. 3 
corresponds to the offer 201 4 shown in FIG. 18. 
[0167] While the invention has been described in 
detail, the foregoing description is in all aspects illustra- 
tive and not restrictive. It is understood that numerous 
other modifications and variations can be devised with- 
out departing from the scope of the invention. 

Claims 
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1. A data processing apparatus (1 t 2, 3) executing a 
process on copyrighted data within a right obtained, 
comprising: 30 

data receiving means (11) operable to receive 
distribution-format data including at least con- 
tent data (42) for protection and billing informa- 
tion (43) defining a billing condition on said 
content data (42); 

right purchasing means (12, 13) operable to 
process payment based on said billing informa- 
tion (43), and obtain a process right (52) 
required for the process on said content data 
(42); 

right information storage means (16) operable 
to store said process right (52) obtained by said 
right purchasing means (12, 13); 
data conversion means (14, 22) operable to 
convert the distribution-format data including 
the content data (42) into internal-format data 
without said billing information (43) when said 
process right (52) is obtained for said content 
data (42); 

data storage means (1 5) operable to store said 
Internal-format data obtained by said data con- 
version means (14, 22); and 
process execution means (17, 18, 19) operable 
to execute the process on said internal-format 
data stored in said data storage means (15) 
within said process right (52) stored in said 
right information storage means (16). 



2. The data processing apparatus according to claim 
1 , wherein 

said content data (42) is encrypted, 
5 said billing information (43) includes a decryp- 

tion key (54) for decrypting encryption of said 
content data (42), 

said data conversion means (14, 22) extracts 
said decryption key (54) from said billing infor- 

70 mation (43), 

said right information storage means (16) 
stores said extracted decryption key (54), 
said process execution means (17, 18, 19) 
decrypts the encryption of said content data 

t 5 (42) using said decryption key (54) stored in 

said right information storage means (16). 

3. The data processing apparatus according to claim 
1 ( wherein 

20 

said distribution-format data includes said con- 
tent data (42), said billing information (43), a 
header (40), and process execution control 
information (41) to control process execution 
25 for said content data (42). 

4. The data processing apparatus according to claim 
1 , wherein 
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. said internal-format data is equal to data 
obtained by separating said billing information 
(43) from said distribution-format data. 

The data processing apparatus according to claim 
1, wherein 

said process execution means (17, 18, 19) 
comprises data copy means (19) operable to 
copy said internal-format data stored in said 
data storage means (15) to a removable stor- 
age medium (7), and 

said data conversion means (22) converts said 
distribution-format data into said internal-for- 
mat data based on a type of said storage 
medium (7). 

The data processing apparatus according to claim 
5, further comprising 

storage medium detection means (23) opera- 
ble to detect the type (35) of said storage 
medium (7), wherein 

said data conversion means (22) converts said 
distribution-format data into said internal-for- 
mat data based on the type (35) of said storage 
medium (7) detected by said storage medium 
detection means (23). 
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7. The data processing apparatus according to claim 
5, further comprising 

storage medium specifying means (24) opera- 
ble to specify the type (36) of said storage s 
medium (7), wherein 

said data conversion means (22) converts said 
distribution-format data into said Internal-for- 
mat data based on the type (36) of said storage 
medium (7) specified by said storage medium w 
specifying means (24). 

8. The data processing apparatus according to claim 
5, wherein 

15 

said distribution-format data includes one or 
more pieces of said content data (42), and 
said internal-format data includes only content 
data to be copied to said storage medium (7) 
among the one or more pieces of said content 20 
data (42). 

9. A data processing method for executing a process 
on copyrighted data within a right obtained, com- 
prising: 25 

a data receiving step of receiving distribution- 
format data including at least content data for 
protection and billing information defining a bill- 
ing condition on said content data; 30 
a right purchasing step of processing purchas- 
ing based on said billing information and 
obtaining a process right required for the proc- 
ess on said content data; 

a right information storing step of storing said 35 
process right obtained in said right purchasing 
step; 

a data converting step of converting the distri- 
bution-format data Including the content data 
into internal-format data without said billing 40 
information when said process right is obtained 
for said content data; 

a data storing step of storing said Internal-for- 
mat data obtained in said data converting step; 
and 45 
a process executing step of executing the proc- 
ess on said internal-format data stored in said 
data storing step within said process right 
stored in said right Information storing step. 

50 

10. A recording medium with a program recorded 
therein, said program for executing, on a computer, 
a data processing method of processing copy- 
righted data within a right obtained, said method 
comprising: ss 

a data receiving step of receiving distribution- 
format data including at least content data for 



protection and billing information defining a bill- 
ing condition on said content data; 
a right purchasing step of processing purchas- 
ing based on said billing information and 
obtaining a process right required for the proc- 
ess on said content data; 
a right information storing step of storing said 
process right obtained in said right purchasing 
step; 

a data converting step of converting the distri- 
bution-format data Including the content data 
into internal-format data without said billing 
information when said process right is obtained 
for said content data; 

a data storing step of storing said internal-for- 
mat data obtained in said data converting step; 
and 

a process executing step of executing the proc- 
ess on said internal-format data stored in said 
data storing step within said process right 
stored in said right information storing step. 
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FIG. 10 




RECEIVE DATA CONVERSION 
INSTRUCTION 



S301 




CONVERT INTO INTERNAL 
FORMAT FOR DVD-RAM 




CONVERT INTO INTERNAL 
FORMAT FOR MEMORY CARD 



S306 



CONVERT INTO GENERAL 
INTERNAL FORMAT 



29 



EP 1 081 574 A1 



FIG. 11 
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FIG. 2 5a 
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typedef struct SDAF_ATTR_GRAPH IC_PR0PS 
{ 

enum { TAG.ID = 0x0001 } ; 
SDAF.ATTR width; 
SDAF.ATTR height: 
SDAF_ATTR bitDepth; 
} SDAF_ATTR_GRAPHIC_PROPS ; 

typedef struct SDAF ATTR_GRAPH IC.CODEC ; 

{ 

enum { TAG_ID = 0x0002 } ; 
SDAF_ATTR codec: // 0: JPEG, etc 

SDAF_ATTR compression: // 0: RLE. l:LZW. etc 
} SDAF_ATTR_GRAPHIC_CODEC: 



44 



EP 1 081 574 A1 



FIG. 2 6 



2071 



CEL SI 



CEL #2 



CEL ftn 



2072 



CEL IDftt 


5 


CEL ID#2 




• *• 




CEL IDftm 


5 


"V 




2073 


2074 



45 



EP 1 081 574 A1 



cp 
> 
o 



8 



csi 

6 



CM 

CO 



s 

CD 
C „ I 

°1 

T3 to 
o 

c •»-» 



to 



CO 



•S2 £ 



c 

=3 



CO 



CM 
CO 

Eg 



CP CD 

CD CP 
O. O. 



co 



CM 



I 



> CO 



o 



hh CO 



CD 

CD 



CM OO 
CO CM 

fee 



GO O 
CO 



CD 
•t-i 

S* 

••H 

o> o 
* * 



CO CO 



CO CO 



CP CP 
no 

CP CP 

Q. D. 



CP 

-*-» cp 

O •«-• 

CP 

CP CO 



£° 

CP 4-> 

3 & 

CP O 
S CP 
CX 



CP >* 
CP 



1 
I' 

<*-> 
O 

g 

+-> 

CO 



CP 
CP 

ex 



CP 



ssas 

o o o 

CO CO CO 



46 



EP 1 081 574 A1 




47 



EP 1 081 574 A1 



FIG. 2 9 



TITLE 2101 



PLAYLIST 



UPC 

VERSION 
LANGUAGE 



PLAYLIST 
2105 



TRACK + 
MENU *? 
SLIDESHOW * 
METADATA * 
ASSOC * 
URL * 



NAME 

ARTIST 

PRODUCTID 

THUMBNAILTD 

ONSTART 



TRACK 2106 



MARKER * 

MENU ? 
SYNCSLIDESHOW* 

SLIDESHOW * 

SYNCTEXT * 

TEXT * 

VIDEO ? 

FILE * 

METADATA * 

ASSOC *• 

URL *• 



ID 

NAME 
ARTIST 
ISRC 
AUDIOID 



TSMID 

thOmbnailid 



MARKER 2107 



TIME 
NAME 



TO MENU2117 
SYNCSLIDESHOW 2108 



TO METADATA2102. 

ASSOC2103. 

URL2104 



-TO MENU2117 
-TO SLIDESH0W2110 
►METADATA 2102 



(PCDATA) 



TYPE 



L*- ASSOC 2103 



ASSOC 
REF 



■URL 2104 



MENU | SLIDE 


+. 


SYNCMAP 


+- 


ID 




NAME 




TYPE 




LIDESHOW 2110 


MENU | SLIDE 


+: 


ID 




NAME 




TYPE 




INTERVAL 






TO SLIDE2116. 
MENU2117 



SYNCMAP 2109 



MENUID 
PLAYID 
TIME 



.TO HENU2U7 
SLIDE 2116 ' 



ID 

NAME 
BACKGROUNDS 



-SYNCTEXT 2111 




SYNCTEXTBLOCK 
2112 



(PCDATA) 



TIME 



-TEXT 2113 




DEO 2114 



ID 

VIDEOID 



TYPE 



►FILE 2115 



(PCDATA) 



ID 

TYPE 



ID 

FILEID 



TYPE 



48 



EP 1 081 574 A1 



FIG. 3 0 
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FIG. 3 2 
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FIG. 3 8a 
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